Columbia Kermit/kermit.zip/newsgroups/misc.19941221-19950208/[e-mail]_Mon Feb 6 07:49:31 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA11480
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 6 Feb 1995 22:37:12 -0500
Received: by apakabar.cc.columbia.edu id AA04951
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 6 Feb 1995 22:37:10 -0500
Path: news.columbia.edu!news.cs.columbia.edu!news.pipeline.com!news.intercon.com!panix!news.mathworks.com!udel!gatech!newsxfer.itd.umich.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit TSR for background xfers?
Message-Id: <[e-mail]>
Date: 6 Feb 95 13:49:31 MDT
References: <3go00i$[e-mail]> <[e-mail]> <3h5mj8$[e-mail]>
Organization: Utah State University
Lines: 58
Apparently-To: [e-mail]

In article <3h5mj8$[e-mail]>, [e-mail] (Leslie Mikesell) writes:
> In article <[e-mail]>,
> Joe Doupnik <[e-mail]> wrote:
>
>>> If so, the kermit would save me a BUNCH.  I need to provide a remote unattended
>>> file xfer solution to 40,000 DOS boxes and realy need a good and cheap solution.
>>-------------------
>>    Let's look at this case. Basically you want MSK to become a TSR Kermit
>>file server. Of course, it's not designed that way now; file server yes,
>>TSR no. Doing file i/o as a TSR has a substantial collection of technical
>>problems because DOS itself is not reentrant and provides no multitasking
>>capabilities. Experiences with DOS' PRINT TSR should be enough to persuade
>>folks that these background transfer guys can be bad news. In addition,
>>a program even the size of Kermit-Lite use substantial amounts of
>>conventional memory, making multiple tasking awkward for the user.
>
> I'm running a DOS program called ACCESS PLUS that is intended to be used
> with the attmail service that uses a 60K TSR to provide scheduled calls
> in the background.  It is running on many machines without causing too
> much trouble from being a TSR, so it is at least possible.  It appears
> to run an xmodem-like protocol modified so that the total packet size
> is 256 bytes, and has a minimal scripting language for dialing and
> login. However, there are things I don't like about the rest of
> this package.  I'd like to replace it with something that does MIME
> attachments without losing the ability to do the background communication.

    Appears to be just one piece of a larger system, and a piece
which does not attract much attention by itself.

>>    There are systems with time sharing capabilities designed into them.
>>The best known are OS/2 and Unix, with OS/2 providing DOS services in a
>>familiar and managable form.
>
> All of which require at least a 386 and a bunch of memory.  A 60K TSR
> can find a cheaper home.

    So, that's the norm these days, what with Windows and such.

>>    We could make a Kermit-Lite which went TSR and tried to cope with
>>the horrid problems of doing DOS i/o from interrupt level. It's not easy
>>so this would have to become a fully funded project rather than a to-do
>>item on our wish list.
>
> I don't have enough sites to justify this myself, but I think there is
> a market for a generic solution to this problem, especially in the

    I disagree here. The market is for the big scale product, not
a tailor-made component. There is no interest at this end in becoming
a parts supplier for free.
        Joe D.

> form of a scriptable kermit TSR since it would allow just about any
> host on the other end.  Especially if it could easily be set up to
> transport messages for something like Pegasus, using only a kermit
> server and a native mail system at the host side.
>
> Les Mikesell
>   [e-mail]